



User Interface Design

Virtual Telephone

by Jas96p






Design Brief



Introduction

	This brief and project attempt to design a graphical user interface (GUI) which would be suitable for the next generation of telephone. The telephones are supposedly for use within an institution such as a University.
	The actual specification states:

	'Assume the desktop computer is now powerful enough to incorporate the desired facilities (of a phone), that is, all the facilities will be integrated into the computer so there will be no handset (i.e. the user speaks and listens into the computer screen, which includes a speaker and a microphone). The GUI should, as a minimum, support the functionality of the present telephone interface. If you feel it is appropriate, extra functionality may be added.'

	This design attempts to solve the specification problem by looking at how to create a 'virtual' phone interface which can act like the real thing, and is simple and easy to use yet supporting a variety of features. As this course is specifically aimed at the design of the interface and not program functionality some of the functions of the interface design will not actually work (i.e. the buttons will not actually DO anything). Also some of the buttons may produce unusual results, but these shall be explained later.




Requirements and User-base

	The project is based around designing the interface for a Virtual Phone and as such the interface has certain fundamental requirements for a phone, and some because it is a computer interface.
	The basic requirements for this project are:

* The GUI supports the basic functions of the existing telephone i.e.
* Numbers from 1 to 0 are represented.
* The # and * keys are represented.
* Dial, Hangup, and Answer facilities are catered for.
* The functions of a basic phone - Memory, Last number redial and Secrecy are present.
* Extended Functions as would be required from the advanced capabilities of a computer are also supported:
* A built in Phonebook.
* A volume option.
* Options to change from loudspeaker to headphones and back.
* A Quit option.
* A Help function.

	Any other options would be regarded as extra and are therefore not basically fundamental to the design itself. The first set of requirements are crucial to the operation of any phone ands so must be included in any phone design, though the actual implementation of those elements may differ. The second set of requirements are those which would go hand in hand with a 'virtual' phone and without which the phone would be more difficult and annoying to use. They in themselves are not essential to the phone, but are essential to the operation of a phone in a computer/office environment, such as that found in a University.

	Thus the user base of this phone design is going to be those sorts of people found within the University setting, e.g. Lecturers, Researchers, Postgraduates, Administrative Staff and many others. It is aimed at the sort of person who will be sat in front of a computer for any part of the day and who may find it advantageous to have a built-in telephone on their system. They will require a phone which supports all the basic functions of an ordinary telephone, plus the extra options essential for computer use as well as possibly optional extras. Users from this area will possibly not require functions in the phone such as those found in secretarial switchboards e.g. Call-redirect, hold, and multiple line support. These could be written into a design but are not relevant to the user-base at which the GUI is aimed.

	A small amount of customer research was carried out and several people who work in an office environment were asked what sort of features they would like to see in a Virtual Phone system. The 'customers' included Support personnel and Postgraduates at several Universities, and also Systems Support personnel at large companies. From their comments further functionality was considered for the design of the Virtual Phone.


Designs, Alternatives and Usability Issues

The most fundamental part of the design of the phone is likely to be the actual dialling part, the bit with the numbers. The question is, what sorts of designs are there.
For the answer it was really a case of looking at existing telephones and the designs which they use. Really, there are two main designs of telephone number dialling segments; The old circular style, and the more common numeric keypad style. Obviously for the purposes of it being a virtual phone there is the consideration of how the numbers will actually be dialled; By mouse, by hand, or even perhaps by voice activation. It makes the best sense for users to be able to dial a telephone number in as many ways as possible, thereby giving a greater flexibility to the design of the phone and so it is usually a good idea to include multiple modes of input for the phone. 
	A design which utilises a circular dial would look similar to an old style telephone, there would be a large circular region within the interface which would contain the number buttons (as it is obviously impossible to actually dial the number as in the old style). There at least two ways of doing this:
1)  The numbers are individual and distinct buttons which go round in a circle. Or
2)  The numbers are all part of one larger circle which is divided into segments. Each separate segment forms an individual button.

	It is known that the latter of the above two methods has been tried and that it did not work very well. Initially it was fine, but the system slowed down dramatically after a short period of time. However, had it worked it would have been a very good method of dialling. The design of the dial would allow expert users to skirt around the centre of the dial to input the number, reducing mouse movement and therefore increasing speed and efficiency of dialling. Novice users on the other hand could use the outer part of the dial which is larger and is easier to use.
	The former of the above methods would perhaps be stylish but it would perhaps not be as practical. The numbers would be too far away from each other to make the interface efficient, and the required size of the buttons may make it difficult to use.
	A numeric keypad design is now a more common design for the majority of telephones and is a design to which more people can associate. The numeric keypad, on a computer is different to that on a telephone so for the interface design there are at least two options. The phone-style, or the keyboard style. Each of which has little advantage over the other. Frequent computer users will find the keyboard style easy to use, and frequent phone users will find the phone-style easy to use. However, as the design is for a computer phone, is can be assumed that the users will have a certain amount of experience with a keyboard and with a telephone, thereby making neither style better than the other.
	Also there is the option of being able to type the number in straight from the keyboard. This would save time compared to that during which the mouse is used. In order to properly accommodate most of these options a numeric readout screen should be shown on the interface, which shows the telephone number as you are dialling it. There the question is where to place it on the interface. Obviously the best solution is near to the dial. But at which point. The best place would be above the dial, as this, Psychologically, would be the easiest place to read it from. Allowing users to input a number from the keyboard increases the usability of the interface and makes it more user-friendly. 

	After the dial and readout there are the other essential functions to think about. The Dial, Hangup and Answer buttons each need to be somewhere sensible and easy to use. They should be large enough to make them easy to 'hit' while not take up too much room. These are three of the most important buttons and thought should be given to where they are placed in relation to the other buttons. It makes sense, at least for Right-handed people, to have these buttons to the right hand side of the dial and readout, as this is more 'friendly' for them to use. Obviously a left handed person would prefer them on the Left hand side. The reason is that when using a mouse it is often easier to manipulate objects to the right of another, important object. This could be due to a psychological 'Reaching Across' belief. If you are concentrating on something in front of you and have to pick something else up, it is preferable to pick it up with your right hand, and therefore preferable to pick it up on your right hand side, without having to reach across your field of vision. Obviously this would not actually happen on a computer screen but some sort of psychological transference may make the user 'think' in the same way as if they were reaching for a physical object.
	Thirdly there are the other function buttons. These are the redial, memory, and secrecy buttons. They are less important than the dialling function buttons and are less often used. Therefore they can be put somewhere which is more out of the way and less often used. Again size may be important, not too big, not too small, and they should really be together, or at least near to each other.

	Finally consideration must be given to any other functions which may feature in the interface. It could be that a large interface window it used containing lots of other buttons, each of which relates to a function, or it could be that the extra options are menu driven. It would depend upon what the function was and how important it was to the interface. The two most important extra functions which may be frequently used would possibly be a Volume control and a Method of reception toggle. These two things could be on the main interface window, but should be sufficiently out of the way as to not hamper the functionality of the critical area of the phone (the dialling section). Other options could be menu driven. This allows them to be present in the interface without being obtrusive, and yet when they are needed they are easily accessible and used. 

	There are many ways in which the GUI could be designed and laid out, it would mostly depend upon the designers personal tastes and his beliefs as to how users will respond to and use the Interface. 


Actual Design

	The actual design uses a phone-style numeric keypad such as that found on most phones. The keys * and # are included as a user would find them on an ordinary phone. This is because it is almost identical to a common telephone and is therefore more familiar to first-time users. The buttons are laid out next to each other so it is fairly easy and quick to dial a number using the mouse. 
	A small input screen is situated above the keypad. This shows what number is being dialled as dialling takes place, and also allows for input directly from the keyboard. This screen is above the keypad for the reasons mentioned earlier. Just above the input screen is a second field. This field shows the name of any person calling you, provided that the computer system and the two telephones can identify themselves to each other. 
	Next to the keypad is a large Answer button. This is large because it is a very important button. When a call is incoming, it may be necessary to pick up the phone in a hurry. Therefore a large button allows this to occur quickly and easily without too much hassle. Above this and next to the two text fields are the Hang Up and Dial buttons. The Dial button is placed almost next to the text field containing the number the user is dialling. This is because it is 'friendlier' to read across the number you wish to dial and then hit Dial. The Hang Up button is above it, next to the Caller Id field since it is again 'friendlier' to hang up when you can also see who it was that was calling you. 
	The function keys, Mute, Redial and Memory are to the left of the keypad as they are less often used, but are still important functions. They deserve to be near to the keypad, but not in a highly used place, i.e. to the left. A Clr function button has also been included which blanks the number input screen should a mistake be made. It would be better if the Clr function merely removed the last character from the number, but as this is a design exercise and not a test of programming, I have not gone to the extent that this works completely correctly.
	To the far right of the interface are the Volume control and the Reception mode selector. These are worthy of inclusion on the main interface but have been put further away because they are not as important to the dialling process.

	Other functions have been added to the design, and these can be accessed via the menu. Functions include the File option, an Answering Machine service, a Phonebook, Advanced options and a help option. The File Option contains the Quit function, and an Import Phonebook function for using other, different phonebooks. 
The Advanced option includes a Notepad function (which can be altered to support any platform - atm it supports emacs), Call-time and Call-charge options. The phonebook supports just reading the entries as well as amending the existing phonebook. The Answering machine includes facilities for recording and playing back of you own messages, as well as setting the delay after which the machine turns itself on, and the actual turn on/off function. Finally the help option contains the Help information, and the obligatory About... option which every windows application seems to possess.
	Some of these functions actually work (Quit and Notepad) while the majority merely depict what they would do in a fully functional model Virtual Phone.

	For actual phone functionality, the Dial button is rendered disabled until a numerical button is pressed, and the Answer button is rendered disabled until an incoming call is received. Once a number is dialling the Dial button is again rendered disabled and remains so until another numerical button is pressed. In the functional model the Memory button would be able to activate the Dial button so that the stored telephone numbers could be used. Once an incoming call has been answered to the Answer button becomes disabled again until another call is received. The mute button displays the Caller Muted button in the top left corner of the window, and when the redial button is pushed, it simulates an incoming call, and displays an 'Incoming Call' box in the corner as well.

Extensions

	Further extensions to this project would be to create a phonebook application which could store lists of telephone numbers and the user could dial a number by selecting it from the phonebook (like bookmarks in Netscape). Other things to include would be a database associated with each number in the phonebook so that the user could bring up information on their caller, or call which  may be of use during the call. It could also be viable to send faxes/e-mails/Business-card like attachments along with the phonecall and so the Virtual Phone would become a multimedia communication system. 
	Options found within businesses could also be added, such as Transfer, Hold and Call-Divert, as well as Teleconferencing and Reminder Calls.

	There is massive scope for the capabilities of the Virtual Phone, it could utilise a vast diversity of functions and options.
James Stuart		Page 7



